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După parcurgerea etapei de studiere a sistemului existent şi de determinare a cerințelor 
sistemului, pentru a avea o imagine mai clară asupra principalelor componente ale sistemului se 
impune crearea unor modele grafice ale acestuia, cu ajutorul diferitelor diagrame. Modelarea 
conceptuală, (logică) a sistemului reprezintă începutul activităților cu caracter tehnic din 
dezvoltarea unui sistem, cu scopul de a completa specificaţiile de analiză şi pentru o reprezentare 
cuprinzătoare a elementelor ce vor fi supuse proiectării. 

Documentaţia descriptivă este un mijloc de comunicare între toți cei implicați în dezvoltarea 
unui sistem, dar nu este, de multe ori, cea mai bună cale pentru reprezentarea cerinţelor unui 
sistem. Modelarea foloseşte o combinaţie între formele descriptive şi grafice pentru descrierea 
cerinţelor privind funcţiile (procesele), datele şi comportamentul sistemului de o manieră relativ 
uşor de înțeles. Dar, poate cel mai important aspect al modelării îl constituie flexibilitatea pentru 
corectarea, completarea şi asigurarea consistenţei reprezentării sistemului. 

Pentru validarea cerințelor este necesar ca ele să fie analizate din mai multe puncte de vedere 
(ale utilizatorilor, beneficiarilor sau celor care finanţează dezvoltarea sistemului, precum şi din 
perspectiva proiectanților). De aceea, modelarea poate fi mijlocul prin care cele trei perspective pot 
fi reunite, determinând şi creşterea probabilității de detectare a erorilor, de eliminare a 
incosistențelor, precum şi de depistare a eventualelor omisiuni. 

Cerinţele sistemului privind funcțiile (procesele), datele şi comportamentul sistemului sunt 
modelate apelând la diferite forme de reprezentare grafică. Pentru obţinerea viziunii de ansamblu 
asupra sistemului se creează modelul descompunerii funcționale, după care se apelează la 
modelarea proceselor, cu ajutorul diagramelor fluxurilor de date (DFD), care indică modul în care 
datele sunt supuse transformărilor în cadrul sistemului, pentru obținerea ieşirilor. Modelarea datelor 
defineşte obiectele, atributele şi relațiile dintre ele, prin intermediul diagramelor entitate-relație 
(DER), în timp ce modelarea comportamentului urmăreşte redarea impactului diferitelor 
evenimente asupra proceselor (ce declanşează şi când procesele de prelucrare), apelând la 
diagramele stărilor de tranziţie, arborii/tabelele decizionale etc. 

Notă: Modelarea sistemului poate să apară necesară şi atunci când se efectuează analiza 
sistemului existent şi nu există documentaţie pentru acesta. După modelarea sistemului existent, 
diagramele obţinute se vor modifica pentru a fi adaptate la cerințele identificate pentru noul sistem. 


5.1 Descompunerea funcţională 


Unul din principalele obiective ale analistului de sistem constă în extragerea cerințelor din 
activitățile curente ale utilizatorilor şi transpunerea lor sub forma procedurilor din cadrul 
aplicaţiilor. De exemplu, dacă un utilizator specifică faptul că primeşte facturile de la furnizori şi le 
plăteşte 30 de zile mai târziu, el explică activităţile curente specifice primirii şi plății facturilor. 
Atunci când analistul creează specificaţiile tehnice pentru cerințele utilizatorilor el, de fapt, 
formulează specificaţiile astfel încât să existe posibilitatea transpunerii cerințelor activităților 
curente într-un mediu informatizat. În aceste condiţii, sistemul trebuie să funcţioneze pe baze 
logice. Soluţiile logice nu permit întotdeauna tratarea proceselor prin folosirea aceloraşi proceduri 
utilizate în lumea fizică. Cu alte cuvinte, sistemele sunt implementate pentru a oferi o serie de 
funcţii, într-o manieră diferită şi mult mai eficientă, pe care utilizatorii le efectuează în activităţile 
fizice curente. De aceea, sistemele informaţionale pot fi gândite ca o soluţie logică a lumii reale. 
Această abstractizare, numită deseori echivalență logică, este un proces pe care analistul trebuie să- 
| desfăşoare pentru modelarea cerințelor efective ale unui sistem. 

Cel mai important pas în obţinerea echivalenţei logice a unui sistem o constituie 
descompunerea funcțională, prin care se identifică principalele componente ale unui sistem (funcții, 
procese, proceduri de prelucrare ş.a.), în urma căreia se obține o diagramă a descompunerii 
funcționale. 

În reprezentarea sistemului cu ajutorul unei astfel de diagrame se ţine cont de faptul că 
sistemul este văzut ca o funcţie pe nivelul cel mai înalt, şi se foloseşte simbolul (dreptunghi) de 
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redare a acesteia o singură dată, după care, pe celelelalte niveluri de descompunere, se foloseşte un 
alt simbol (dreptunghi cu colţurile rotunjite) de redare a proceselor, diferit de cel al funcţiei, aşa 
cum se va vedea în continuare. O altă regulă, care se va menţine şi în modelul proceselor, o 
constituie denumirea în mod unic a fiecărui proces. 

Descompunerea funcțională este utilă atunci când se doreşte studierea unei singure 
componente din sistem, permiţând o mai uşoară înțelegere a modului în care este structurat 
sistemul, precum şi posibilitatea realizării de modificări sau completări la nivelul acestuia. 

Diagrama descompunerii funcționale poate fi văzută ca şi organigrama unei organizaţii, în care 
poziția de pe cel mai înalt nivel o constituie sistemul, văzut ca funcție de bază, iar nivelurile 
inferioare de descompunere sunt procesele din care este alcătuit, aşa cum rezultă şi din fig. 5.1 


Sistem 


Nivel "0" 
de descompunere 


Tranzactie 1 Transformare 2 Tranzactie 3 Tranzactie 4 


Nivel "1" 
de descompunere 


Proces 1.1 Proces 1.2 Proces 1.3 Proces 3.1 Proces 3.2 


Nivel "2" 
de descompunere 


Procedura 1.2.1 Procedura 1.2.2 Procedura 1.2.3 


Fig. 5.1 Diagrama descompunerii funcționale 


În figură s-a reprezentat un sistem pentru care s-au identificat mai multe tranzacţii şi 
transformări (funcțiile principale ale sistemului), din care doar două se descompun pe următorul 
nivel în procese de prelucrare, iar din aceste procese doar unul se descompune mai departe. Nu este 
o situație standard, pentru că toate tranzacțiile, procesele şi procedurile se pot descompune pe 
niveluri inferioare, în funcţie de complexitatea lor. În terminologia construirii modelului sistemului 
pentru redarea conceptului de prelucrare, indiferent de nivelul pe care se situează, se foloseşte 
noţiunea de proces, care face referire inclusiv la tranzacții/transformări, proceduri, module, grupuri 
de instrucțiuni, pentru că toate urmăresc prelucrarea datelor. 

De asemenea, din modelul prezentat în figura 5.1 trebuie reținute următoarele aspecte: 

e barele care delimitează nivelurile de descompunere sunt doar didactice, de evidenţiere a 

acestor niveluri (ele nu apar în realizarea diagramei!!!); 

e denumirile de niveluri, ca şi în cazul barelor de delimitare, apar pentru a reliefa doar modul 
de tratare a fiecărui nivel de descompunere. Astfel, primul nivel de descompunere este 
considerat „0” pentru că porneşte de la nivelul cel mai înalt, care ar fi numerotat cu 0. 
Următorul nivel este „1” pentru că s-a obţinut din descompunerea unui proces ce se afla pe 
primul nivel de descompunere ş.a.m.d.; 

e  numerotarea pe trepte de cifre (1, 1.1, 1.2.1) redă tocmai poziţia procesului în cadrul 
structurii de descompunere, în sensul că procesul 1 se află pe nivelul 0, pentru că de fapt 
numerotarea lui ar fi trebuit să apară sub forma 0.1 (dar în informatică cifra 0 plasată în 
faţa altei cifre se ignoră). Procesul 1.1 se află pe nivelul 1, pentru că se află pe prima 
poziție imdeiat după nivelul O etc. 
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Aceste comentarii ar trebui reţinute pentru că nivelurile de descompunere vor fi folosite mai 
târziu în construirea modelului proceselor cu ajutorul diagramelor fluxurilor de date, în sensul că 
„scheletul” acestor diagrame se construieşte plecând de la diagrama descompunerii funcționale. 

Diagrama descompunerii funcționale poate fi construită apelând la două metode: bottom-up 
sau top-down, uneori mixtă. Însă de cele mai multe ori, se foloseşte metoda top-down. 

În cazul bottom-up, analistul trebuie să identifice cele mai de jos proceduri de prelucrare, pe 
care să le grupeze apoi, în funcție de anumite caracteristici comune, în procese până se ajunge la 
clase de tranzacţii şi se consideră că este complet sistemul. În acest caz, diagrama descompunerii 
funcționale poate fi obținută după ce au fost construite DFD-urile. 

În cazul top-down, se parcurge sensul invers al acţiunilor, cu alte cuvinte sistemul se 
descompune până la cel mai de jos nivel. În acest caz, diagrama descompunerii funcționale stă la 
baza construirii DFD-urilor, adică se va obține câte o diagramă a fluxurilor de date pentru fiecare 
ramură de descompunere şi va exista un control mai riguros asupra descrierii proceselor din cadrul 
sistemului. În plus, cu ajutorul instrumentelor CASE, există posibilitatea generării automate a 
structurii de bază a DFD-urilor (selectarea proceselor de prelucrare de pe acelaşi nivel şi plasarea 
pe o singură diagramă de nivel) din diagrama descompunerii funcționale. 

Cazul mixării celor metode apare atunci când există deja modelul funcțional al sistemului şi 
sunt necesar diverse ajustări prin adăugarea de noi procese sau eliminarea altora, în funcție de 
cerințele noului sistem. 


5.2 Modelarea logică, grafică a fluxurilor de date şi 
a prelucrărilor — diagramele fluxurilor de date (DFD) 


Intr-o definiție restrânsă, DFD-urile sunt o metodă de prezentare grafică a traseului logic pe 
care îl parcurg datele prin diverse procese până sunt trasnformate în ieşiri. 


5.2.1 Diagramelor fluxurilor de date — prezentare generală 


DFD-urile pot fi folosite în locul unei descrieri narative a sistemului, ce vine în sprijinul 
analiştilor în timpul dialogului cu utilizatorii. Acest lucru se datorează faptului că analiştii sunt 
confruntați de multe ori, în timpul întâlnirilor cu utilizatorii, cu problema explicării modului de 
funcționare a sistemului, când utilizatorii sunt puşi în situația de a accepta sau refuza soluţiile 
propuse pentru dezvoltarea unui sistem şi nu pot da un răspuns pentru că nu reuşesc să înțeleagă 
specificaţiile prea ample şi complex formulate. Din experiență, s-a constat că oamenii reuşesc să-şi 
amintească 100% din imaginile văzute, dar numai 50% dintr-un text. De aceea, reprezentarea 
grafică a unui sistem poate oferi utilizatorilor o modalitate mai simplă de a-l înţelege, precum şi 
modul în care el le va rezolva problemele. 


5.2.1.1 Rolul DFD-urilor 


Scopul diagramelor fluxurilor de date (DFD), pentru o anumită componentă organizatorică sau 
funcțională la care se referă (secţie, birou, compartiment, întreaga unitate, o anumită activitate — 
vânzări, cumpărări, încasări, plăţi ş.a.) este de a scoate în relief, într-o manieră cât mai sugestivă, 
următoarele aspecte: 

e sursa datelor de prelucrat, 

e operațiunile de prelucrare prin care trec datele; 

e destinația datelor prelucrate; 

e legătura existentă între prelucrări şi activitatea de stocare a datelor. 

Cu ajutorul diagramelor fluxurilor de date se pot stabili granițele unui sistem apelând doar la 
patru simboluri: 
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e locul în care se vor duce informațiile sau de unde vin, văzut ca alt sistem sau altă persoană 

care interacționează cu sistemul; 

e locul în care sunt păstrate/memorate datele care circulă în sistem; 

e fluxul de date; 

e procesul care asigură transformarea datelor. 

Aşa cum se va vedea mai târziu, primele două simboluri sugerează originea, respectiv locul 
final în care ajung datele la un moment dat. 

DFD-urile pot fi utilizate pentru reprezentarea unui sistem sau a unui software la orice nivel de 
abstractizare. Propriu-zis, DFD-urile pot fi descompuse pe niveluri ce indică o creştere a detalierii 
fluxurilor de informații şi a prelucărilor. De aceea, DFD-urile oferă un mecanism pentru modelarea 
atât a fluxurilor de informaţii, cât şi a proceselor, aşa cum rezultă din figura 5.2. 


Entitate externa 


Entitate externa 


Tranzactie 1 


'Bate- 
j intermediare- 
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intermediare-2 A intermegiare-3 
N Date- / Tranformare 4 
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Transformare 2 
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Date 
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Yy 


Entitate externa Entitate externa\ 


Fig. 5.2 Model al fluxului informațional şi al prelucrărilor 


În figura anterioară, pătratul folosit redă o entitate externă, adică un element al sistemului 
(hardware, o persoană sau aplicaţie) sau alt sistem care produce informații pentru a fi supuse 
transformărilor sau primeşte informaţii produse de sistem. Cercul reprezintă un proces sau o 
transformare aplicat/ă datelor, prin care datele sunt modificate. Linia cu săgeată reprezintă una sau 
mai multe entități de date, indicând modul în care circulă datele în sistem. Cele două linii paralele 
înseamnă un Joc de stocare a datelor, prin care informaţiile sunt păstrate pentru a fi folosite de 
către procesele sistemului. 

Simplitatea simbolurilor folosite pentru construirea DFD-urilor reprezintă un alt motiv pentru 
care sunt folosite în modelarea şi descrierea sistemului. Însă, trebuie remarcat faptul că nu există 
indicații explicite asupra secvenţei prelucrărilor sau a condițiilor logice de execuție a acestora. 
Procedura sau secvența procedurilor este considerată implicită în cadrul DFD-urilor, iar explicațiile 
detaliate sunt lăsate pentru etapa de proiectare. 

De asemenea, DFD-urile reprezintă primul pas către realizarea schiţei de proiectare a 
sistemului, semnificând transpunerea sub formă grafică a cerinţelor utilizatorilor. 

Aşa cum am prezentat anterior, tehnica diagramelor fluxurilor de date, în general, apelează la 
patru simboluri de bază pentru a reprezenta sistemele informaţionale logice, înlocuind „clasicele” 
scheme logice. Se consideră că, totuşi, schemele logice de sistem, prin care se prezintă configurația 
fizică a sistemului informatic, sunt mai sugestive decât o diagramă; însă pentru toate celelalte 
cazuri diagramele sunt net superioare, îndeosebi pentru reprezentarea logicii sistemelor informa- 
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tionale. Dar şi schemele de sistem atrag anumite critici întrucât, prin apelarea în faza proiectării 
logice la unele simboluri speciale pentru discuri, CD-uri ş.a., se preiau unele caracteristici specifice 
proiectării fizice (doar în această etapă trebuie să se specifice concret echipamentele viitoare şi 
suporturile). 

Revenim asupra principiului de bază al analizei: trebuie să scoată în evidenţă CE face sistemul 
şi nu CUM. De aceea, prin intermediul diagramelor fluxurilor de date se scoate în evidență logica 
sistemului şi operaţiunile care se efectuează asupra datelor, fără să se acorde atenţie detaliilor fizice 
specifice proiectării. 

De aici trebuie reținut că procesele de prelucrare, schimbul de date şi memorarea datelor sunt 
aspectele importante de care trebuie să se ţină cont în modelarea sistemului şi nu modul în care sunt 
transpuse din punct de vedere fizic, cum ar fi un fişier indexat păstrat pe un CD, o interfaţă etc. 


5.2.1.2 Modul în care începe construirea unei diagrame a fluxurilor de date 


De cele mai multe ori, construirea diagramelor fluxurilor de date pleacă de la descompunerea 
funcțională a sistemului, în care a fost identificată structura din care este alcătuit, respectiv 
funcțiile, procesele, procedurile sistemului. De aici, într-o manieră simplificată, se pot parcurge 
următorii paşi: 

1. atenţia se va orienta către un proces (sistemul ca un tot, nivelul 1 de descompunere ş.a.); 

2. se vor identifica elementul sau elementele care inițiază procesul: ce intră în proces? E de 
preferat ca tot ce intră în proces să fie plasat la stânga lui, pentru că mai târziu în timpul 
îmbunătăţirii modelului este foarte uşor să se concentreze atenţia spre intrări numai prin 
simpla lor localizare; 

3. determinarea ieşirilor procesului sau a ceea ce ar trebui să se obțină şi plasarea lor la 
dreapta procesului; 

4. stabilirea tuturor fişierelor, formularelor sau altor componente de care procesul are nevoie 
pentru realizarea completă a transformărilor pe care le presupune procesul. Aceste 
componente sunt, de obicei, locuri de stocare a datelor apelate în timpul prelucrărilor. Ele 
sunt plasate, de obicei, deasupra procesului sau sub el; 

5. ataşarea unui nume şi număr procesului prin rezultatele pe care le oferă. De exemplu, dacă 
un proces conduce la obţinerea facturilor, el poate fi etichetat cu denumirea “Crearea 
facturilor”. Dacă procesul presupune mai mult de un singur eveniment, el poate fi denumit 
folosind conjuncţia “şi”, ceea ce va permite să se determine dacă procesul este o procedură 
primitivă (ce nu mai necesită descompunere) sau poate fi descompus mai departe. De 
asemenea, numele procesului ar trebui să fie cât mai apropiat de ceea ce utilizatorul face în 
activitatea sa curentă. Numărul ataşat procesului permite analistului să-l identifice în 
cadrul sistemului şi, ce e mai important, să stabilească legătura cu nivelurile superioare sau 
inferioare identificate în timpul descompunerii funcționale. 


5.2.2 Simboluri şi descompuneri ale DFD 


Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate apelează la 
operațiunea de modelare logică a datelor şi prelucrărilor sub formă de diagrame, diferențele 
constând doar în folosirea mai pronunţată a diagramelor pentru descrierea sistemului, încadrându-le 
în diagrame de context şi diagrame ale fluxurilor de date logice. Altele apelează la combinații de 
diagrame, tabele şi forme descriptive. 

Diagrama de context scoate în relief aria de întindere a sistemului analizat, prin specificarea 
elementelor din interiorul organizației şi a celor externe, sub denumirea de entităţi externe, 
însemnând entităţi externe sistemului analizat. 

Diagrama fluxurilor de date ale sistemului logic curent, independentă de tehnologie, reliefează 
funcțiile de prelucrare a datelor executate de către sistemul informaţional curent. 
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Diagrama fluxurilor de date ale sistemului logic nou va prezenta circuitul datelor, structura 
lor şi cerințele funcționale ale noului sistem. 

Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicționare ale proiectelor sau depozite 
CASE (repository). 

În literatura de specialitate, toate se regăsesc sub denumirea generică de diagrame ale 
fluxurilor de date. 

Întrucât diagramele fluxurilor de date (DFD) au ca obiectiv urmărirea modului de transfer al 
datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi modele ale 
proceselor de prelucrare, iar operaţiunea se numeşte modelarea proceselor. 


5.2.2.1 Simboluri utilizate în construirea DFD 


În practică, cele mai multe produse apelează la două tehnici de redare a diagramelor fluxurilor 
de date: Gane&Sarson şi Yourdon& DeMarco. Tehnicile sunt destul de asemănătoare, diferenţele 
cele mai vizibile fiind legate de simbolistica utilizată. 

Entităţile externe (EE) sunt numite şi sursă/destinaţie sau agenți externi, fiind locurile de 
unde intră sau către care ies documente, liste, situații, informaţii. Legăturile care se realizează între 
procesele de prelucrare şi entitățile externe, prin intermediul fluxurilor de date, au ca suport 
circuitul unor astfel de documente în cadrul organizației, purtând de multe ori şi denumirea de 
fluxuri externe sau fluxuri finale, pentru că ele vin din afara sistemului (fluxurile de intrare, 
provenite de la entități) sau nu rămân în interiorul sistemului (fluxurile de ieşire, care au ca 
destinaţie entităţile externe). 

Enităţile sunt considerate externe sistemului pentru că nu intră în aria de modelare a 
sistemului, adică procesele prin care aceste entități obțin fluxurile pe care le pun la dispoziția 
sistemului (fluxurile de intrare) sau cele prin care preiau fluxurile din sistem (fluxurile de ieşire). 

Simbolurile convenţionale folosite de cele două tehnici sunt redate mai Jos: 


Gane & Sarson Yourdon & DeMarco 
Pătrat îngroşat Pătrat simplu 


În concluzie, entităţile externe sunt reprezentări fizice ale grupurilor de persoane, cum sunt 
clienţii, furnizorii sau ale altor sisteme, ca de exemplu GESTMAT, SALARII. Uneori, o entitate 
externă poate fi o singură persoană (contabil-şef, preşedinte etc). 


Fluxuri de date 


Fluxurile de date, redate printr-o linie cu o săgeata la unul din capete, sunt utilizate cu scopul 
de a sugera o cale pe care se pot suprapune una sau mai multe structuri de date, în momente 
nespecificate, care intră în procesele de prelucrare sau sunt rezultatul lor. Totuşi, momentul 
prelucrării datelor unui proces poate fi specificat prin descrierea procesului respectiv în dicționarul 
sau depozitul datelor. 

De regulă, fiecare săgeată a fluxului de date primeşte un nume sugestiv, care descrie numai o 
structură de date. De aceea, denumirea fluxurilor începe cu un substantiv care să redea cât mai bine 
faptul că se preia sau transmite o structură de date necesară: 

e unui proces, când trebuie să fie supusă prelucrărilor şi este preluată de la o entitate externă 

sau este rezultatul citirii unor înregistrări anterioare dintr-un loc de stocare; 

e unei entități externe, când este rezultatul unui proces de prelucrare şi este cerută de o 

persoană, un alt sistem, o aplicație, un birou etc.; 

e unui loc de stocare, când, în urma prelucrărilor, pe baza ei se adaugă noi înregistrări, se 

modifică sau se şterg înregistrările anterioare. 

În anumite situaţii se impune însă prezentarea câtorva structuri de date pe o singură săgeată de 
flux, după cum rezultă din figura 5.3. 
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Fig. 5.3 Structuri multiple de date pe un singur flux 


O astfel de situație apare atunci când dintr-un proces de prelucrare rezultă două structuri de 
date diferite, dar care trebuie să ajungă simultan fie într-un alt proces de prelucrare, fie la o entitate 
externă. Un caz asemănător se întâlneşte şi atunci când într-un proces de prelucrare intră în acelaşi 
timp, de la aceeaşi sursă, fluxuri diferite ca structură (de exemplu, de la depozit vin documentele 
privind mişcările de materiale dintr-o perioadă de timp, care au structuri de date diferite, dar sunt 
necesare toate pentru actualizarea stocului de materiale). 

Se mai întâlneşte o situație aparte atunci când se doreşte redarea unei ramificații a aceleaşi 
structuri de date, ceea ce înseamnă că un flux se poate descompune, la un moment dat, având o 
singură origine şi multiple destinaţii, aşa cum ilustrează şi exemplul din fig. 5.4. 
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Fig. 5.4 Flux de date cu o singură origine şi cu mai multe destinații 


Trebuie reţinut că prin fluxurile de date nu se redau şi circuitele bunurilor fizice, ci numai 
datele care reflectă aceste circuite. De exemplu, este incorect să se includă într-o diagramă fluxul 
“Produse livrate”. Fluxul corect ar trebui să fie “Documente livrare produse”. 

Aşa cum s-a menționat şi la descrierea entităților externe, fluxurile de date se pot încadra în 
două categorii: 

e externe, cele care provin de la entitățile externe şi sunt supuse proceselor de prelucrare, 
respectiv cele care sunt rezultatul unui proces de prelucrare şi au ca destinaţie entitățile 
externe; 

e interne, cu referire la fluxurile care circulă între două procese de prelucrare sau între un 
proces şi un loc de stocare. Sunt considerate interne, pentru că ele provin din interiorul 
sistemului (un proces de prelucrare sau un loc de stocare), respectiv nu părăsesc sistemul 
(merg într-un alt proces de prelucrare sau într-un loc de stocare). 

Cei care modelează sistemul prin intermediul diagramelor fluxurilor de date trebuie să ţină 
cont de faptul că orice flux de date trebuie să treacă printr-un proces de prelucrare, fie că intră în el 
pentru a fi prelucrat, fie că este rezultatul prelucrării. 

În privinţa simbolisticii folosite de cele două tehnici, nu există diferențieri. 


Locuri de stocare a datelor 
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Locul de stocare a datelor reprezintă un “depozit” pentru datele care sunt înregistrate temporar 
sau permanent în cadrul sistemului, adică cele care se păstrează în sistem pentru utilizări viitoare. 
Ca şi în cazul fluxurilor de date, locurile de stocare nu urmăresc redarea unui format fizic de 
păstrare a datelor, ci reprezintă locaţii sau metode prin care datele sunt păstrate în sistem. Un loc de 
păstrare poate fi un fişier, un director, o tabelă a unei baze de date, o bază de date, un dosar, un 
registru, o înregistrare din agenda unei persoane, inbox-ul e-mailului unei persoane sau chiar 
memoria cuiva. Locurile de stocare pot conţine date despre clienţi, stocuri, comenzi, studenți, 
facturi primite, facturi emise, state de salarii, plăţi, încasări etc. Direcţia fluxurilor de date către sau 
de la locul de stocare indică faptul că datele sunt scrise sau citite în/din acel loc de stocare. În plus, 
orice ştergere sau modificare a unei înregistrări dintr-o bază de date este reprezentată tot ca un flux 
de date, în sensul că o astfel de operaţiune cere ca datele să fie citite înainte de a fi şterse sau 
modificate. Ca urmare, stocarea datelor se referă atât la fişierele sistemelor de prelucrare manuală, 
cât şi la cele create în medii informatizate, inclusiv unul sau mai multe tabele ale bazelor de date. 

Simbolurile utilizate de cele două tehnici sunt: 

Gane & Sarson Yourdon & DeMarco 
Dreptunghi neînchis la dreapta Linii paralele 


Prezenţa într-o diagramă a fluxului de date a unui simbol pentru redarea operațiunii de stocare 
date, care are o singură intrare şi o singură ieşire, conduce la o examinare mai atentă, pentru a se 
trage concluzia dacă acel loc, din punct de vedere economic, este logic necesar. S-ar putea ca 
prezența lui să sugereze un fişier temporar fizic, utilizat cu funcția esențială de mediu de 
comunicare a datelor. 

De exemplu, dacă anumite date se salvează pe o dischetă doar pentru a fi transportate de la o 
filială la sediul firmei, operațiunea nu este logic necesară, cât timp datele pot fi transferate şi 
telefonic. Deci, scopul creării fişierului este acela de a ajuta la operațiunea de transfer date. Pe de 
altă parte, dacă pe aceeaşi dischetă s-ar păstra datele despre clienţii rău platnici pentru a fi 
prezentaţi responsabilului cu vânzările, peste câteva zile, operaţiunea este logic necesară, chiar 
dacă ea are doar o intrare şi o ieşire. 


Exemple: 
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Procese de prelucrare 
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Un proces de prelucrare este o funcție exercitată cu scopul transformării datelor într-o altă 
formă, utilizarea lor pentru crearea unor noi date sau pentru reunirea mai multor date pentru 
obținerea unor informaţii, sub forma rapoartelor, documentelor, situaţiilor etc. 

Atunci când se modelează un proces din punct de vedere logic nu are importanţă dacă el este 
executat de un calculator, un alt echipament sau de către o persoană. Procesele sunt organizate în 
cadrul diagramelor fluxurilor de date într-o secvenţă corespunzătoare ordinii lor de execuţie. Aşa 
cum s-a discutat la descompunerea funcțională, un proces poate fi descompus în componente pentru 
a se scoate în evidență cât mai multe detalii privind prelucrarea datelor. 

Pot fi identificate patru categorii de procese de prelucrare care se fac asupra fluxurilor de date: 

l. crearea unui set de fluxuri de date, pe baza datelor de intrare. Fluxurile noi de date 
reprezintă ieşiri ale procesului şi intrare în alt proces, înregistrare într-un loc de stocare sau 
ieşire pentru o entitate externă. Un exemplu al unui astfel de tip de transformare o 
constituie intrarea informaţiilor privind salariile angajaților într-un proces prin care se 
creează statul de salarii, care are o altă formă faţă de fluxul de intrare; 

2. obținerea de noi informaţii din fluxul de intrare fără transformarea lui, care va fi folosit în 
aceeaşi formă ca o ieşire. O situație des întâlnită o constituie verificarea codului unui client 
în înregistrările anterioare pentru a determina dacă este un client vechi sau nu. Asta 
înseamnă o prelucrare la nivelul înregistrărilor dintr-un loc de stocare, în sensul că în 
proces va intra codul clientului de pe un document (ca flux de intrare), din care va rezulta 
tot codul clientului care se duce în locul de stocare; 

3. reorganizarea datelor de intrare sub o anumită formă, cum ar fi sortarea datelor, 
reformatarea sau filtrarea lor. De exemplu obținerea unei liste a salariaților în ordine 
alfabetică pe baza datelor preluate dintr-un fişier al salariaților, în care ordonarea a fost 
făcută după marcă; 

4. transferarea datelor sau capturarea lor pentru a fi trimise unui alt proces de prelucrare care 
nu are nevoie de toate datele preluate. Un exemplu de astfel de proces constă în preluarea 
preţului produselor prin intermediul POS-ului şi transmiterea lor în procesul de calcul a 
valorii facturii. 

Într-o formă generalizată, denumirea proceselor se face sub forma verb (substantiv verbal) + 
descrierea funcției (rolul) pe care o realizează procesul, fără însă a oferi prea multe detalii. De 
exemplu, este improprie următoare denumire de proces: “Verificarea contului pentru determinarea 
limitei de creditare şi stabilirea situaţiei contului clientului”. Un nume corect de proces ar putea fi 
formulat de genul: “Verificarea clientului”. 

Simbolurile folosite pentru redarea proceselor de prelucrare sunt: 

Gane & Sarson Yourdon & DeMarco 
Dreptunghi cu colțuri rotunjite Cerc 


Ca regulă generală, se recomandă ca erorile sau excepţiile să nu fie tratate în diagrama 
fluxului de date, mai ales în cele foarte ample. Obiectivul diagramei fluxului de date este de a 
scoate în relief fluxul normal al datelor, iar erorile şi excepţiile pot fi descrise ulterior. 


5.2.2.2 Ierarhia diagramelor fluxurilor de date 


În paragraful 5.1 se specifica faptul că diagrama descompunerii funcţionale stă la baza 
construirii “scheletului” diagramelor fluxurilor date, pentru că din ea se generează o serie de 
diagrame ale fluxurilor de date, şi anume: 

e o singură DFD pentru simbolul redat sub denumirea de “Sistem”, cunoscută sub numele 

de diagramă de context; 

e o singură DFD de nivel “0”, în care sunt preluate principalele funcţii în care se 

descompune sistemul pe primul nivel; 
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e câte o DFD de nivel “1”, numărul acestor diagrame fiind egal cu numărul funcțiilor de pe 
nivelul superior care se descompun. În exemplul dat se vor obţine două diagrame de nivel 
“1”, una pentru procesele obținute din descompunerea “Tranzacţie 1” şi o diagramă 
pentru procesele rezultate din descompunerea “Tranzacție 3”. Dacă ar fi fost descompuse 
şi “Transformare 2”, respectiv “Tranzacţie 4”, s-ar fi obținut 4 diagrame de nivel “1”; 

e câte o DFD de nivel “2”, numărul diagramelor fiind dat de numărul proceselor de pe 
nivelul “1” care s-ar fi descompus în proceduri. Pentru cazul luat, se obţine doar o 
diagramă de nivel “2”, pentru redarea procedurilor în care s-a descompus “Proces 1.2”; 

e câte o DFD de nivel “3”, dacă sistemul este descompus în continuare pe acelaşi principiu 
ca în cazul diagramelor de nivel “1” şi “2”. 


Diagrama de context 


Diagrama de context este prima diagramă de fluxuri de date care se construieşte din setul 
obținut în urma descompunerii funcționale. Prezintă cele mai puţine detalii, urmărind să scoată în 
evidență granițele sistemului, prin identificarea legăturilor cu entitățile externe, prin intermediul 
fluxurilor externe de date (de intrare şi de ieşire). Ca urmare, diagrama de context conţine un singur 
simbol de proces, denumit cu numele sistemului şi are atribuit cifra 0 ca identificator. Nu sunt 
prezente locurile de stocare pentru că nu sunt cuprinse procesele prin care se pot face prelucrările 
specifice scrierii sau citirii din aceste locuri. Dacă apar situaţii când sunt prezentate locuri de 
stocare, înseamnă că ele ies de sub sfera de influență a sistemului modelat şi trebuie reprezentate 
sub forma entităților externe. Un exemplu de astfel de diagramă este redat în figura 5.5. 


Entitate externa 
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Entitate externa 


Sistem 


Date =intrare- 


2 


Entitate externa 
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Fig. 5.5 Exemplu generalizat pentru diagrama de context 


Diagrama fluxului de date de nivel “0” 


Singurul proces redat în diagrama de context este reprezentat cu detalii pe următorul nivel, 
respectiv diagrama de nivel “0”. Procesul de trecere de la diagrama de context la următoarele 
niveluri de detaliere este numit generic “explodare”. Prin diagrama de nivel “0” sunt prezentate 
principalele funcții ale sistemului, secvenţa acestor funcții, locurile de stocare accesate, precum şi 
enitățile externe cu care sistemul interacționează. Fiecare funcție are un identificator numeric care 
corespunde secvenţei în care se execută. 

Decizia privind funcțiile incluse de sistem este una deosebit de importantă, dar includerea lor 
în diagrama de nivel “0”este o decizie care se bazează pe subiectivitate. Deşi nu există reguli stricte 
din acest punct de vedere, pot fi urmate câteva recomandări, în sensul că procesele care se includ în 
diagrama de nivel “0” sunt cele care redau una sau mai multe din următoarele acțiuni: 
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e un proces care asigură scrierea şi/sau citirea dintr-unul sau mai multe locuri de stocare a 
datelor; 


e un proces direct responsabil de obţinerea şi/sau transmiterea de date către una sau mai 
multe entităţi externe; 


e un proces care preia datele de la una sau mai multe entități externe; 


e un proces care serveşte ca un descriptor de pe cel mai înalt nivel al paşilor prin care trec 

datele în timpul transformării lor. 

O altă modalitate de abordare a funcțiilor ce pot fi incluse într-o astfel de diagramă se aplică în 
cazul sistemelor care se bazează pe aplicații informatice, caz în care opţiunile din meniul principal 
al aplicațiilor pot sta la baza reprezentării funcțiilor pe nivelul “0”. 

O caracteristică importantă a tuturor nivelurilor de reprezentare a DFD-urilor constă în faptul 
că tot ceea ce este reprezentat pe un nivel superior trebuie să se regăsească şi pe nivelurile 
inferioare. Cu alte cuvinte, toate entitățile externe din diagrama de context trebuie să fie 
reprezentate şi în diagrama de nivel “0” şi pe următoarele nivelurile. Odată ce un loc de stocare sau 
entitate au fost identificate ele trebuie să se regăsească pe toate nivelurile de descompunere 
inferioare. 

Atunci când sistemul este descompus pentru obţinerea diagramei de nivel “0” în procesele sale 
de bază, construirea ei se va baza pe identificarea logică a fluxurilor externe (de intrare şi ieşire) şi 
conectarea lor la procesele corespunzătoare pentru a face legătura cu entitățile externe, aşa cum au 
fost reprezentate în diagrama de context. 

Sunt situații când, pentru simplificarea diagramei de context, s-a recurs la reunirea mai multor 
fluxuri de date într-unul generalizat, dar care în DFD-O intră sau ies din procese diferite. De aceea, 
se impune descompunerea fluxului generalizat în două sau mai multe subfluxuri pentru a reda exact 
procesul în care intră sau din care ies. 

Începând cu DFD-0, îşi fac apariţia fluxurile de date interne, adică cele care fac legătura din 
procesele de prelucrare şi locurile de stocare sau dintre procese. Aceste fluxuri se vor regăsi, în 
mod obligatoriu, pe următoarele niveluri ale DFD, în funcție de procesul din DFD-O care se 
explodează. 

Un exemplu de diagramă de nivel “0” a fost redat în figura 5.2. 


DFD de nivel “1” până la “n” 


După ce diagrama de nivel “0” a fost finalizată şi verificată pentru eliminarea erorilor şi 
asigurarea reprezentării corecte a fluxurilor sistemului, procesul de descompunere continuă cu 
nivelurile de la “1” la “n”. Acest lucru înseamnă că nivelul “0” este descompus pe nivelul “1” şi, 
dacă e necesar, nivelul “1” pe nivelul “2” ş.a.m.d până când se atinge cel mai mare nivel de 
detaliere pentru toate procesele şi subprocesele asociate. Procesele din DFD-O sunt referite, de cele 
mai multe ori, ca procese-părinte (parent processes), iar rezultatul explodării lor, respectiv 
subprocesele, sunt denumite procese-copil (child processes). 

Prima regulă de construire a diagramelor de nivel “1” constă în faptul că un proces-copil nu 
poate primi sau nu poate genera un flux pe care procesul-părinte nu-l primeşte sau nu-l generează. 
Excepţie face situația în care fluxul primit/generat de procesul-părinte este descompus în subfluxuri 
pentru a se stabili legături distincte pentru fiecare subproces, asemănător situaţiei subfluxurilor din 
DFD-0. 

De asemenea, pentru asigurarea principiului de balansare (echilibrare) a diagramelor, fiecare 
proces-copil din DFD-1 este legat de procesul-părinte din care a fost obţinut printr-un sistem de 
numerotare secvențial plecând de la cifrele alocate în DFD-0. De exemplu, procesul “Tranzacție 1” 
de pe nivelul “0” este reprezentat pe nivelul “1” cu trei procese-copil 1.1, 1.2, şi 1.3. Din figura 5.6, 
se poate observa că aceleaşi fluxuri de date care intră sau ies din procesul-părinte sunt reprezentate 
în diagrama de nivel “1”. 
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Fig. 5.6 Exemplu generalizat de diagramă a fluxurilor de date de nivel “1” 


Notă: În diagrama din exemplu, fluxul de date din DFD-0 “Date-de-intrare-1” a fost 
descompus în două subfluxuri: “Date-de-intrare-la” şi “Date-de-intrare-1b”. 

Se ridică o problemă în privința momentului în care ar trebui să se oprească descompunerea. 
Este o decizie la fel de subiectivă, ca şi cea privind stabilirea principalelor funcții ale sistemului, 
dar o recomandare generală sugerează că ultimul nivel de descompunere n-ar trebui să depăşească 
nivelul 7. Procesul de descompunere ar trebui să continue până când toate funcțiile şi procesele au 
fost explodate pentru a evidenția un nivel de detaliere suficient de relevant pentru analiză. Când un 
proces a fost descompus la nivelul solicitat de detaliere el este referit ca o primitivă funcțională, în 
sensul că el primeşte un singur flux de intrare şi generează un singur flux de ieşire. 

O altă recomandare privind descompunerea face referire la faptul că funcțiile (aplicaţiile) 
trebuie să fie explodate pe această cale până ce detaliile logicii procesului sau „primitivele” pot fi 
scrise pe cel mult o pagină de pseudocod. În cazul sistemelor complexe, apar totuşi ca necesare 
nivelurile 3 şi chiar 4. 

Există totuşi anumite reguli pentru a determina momentul încetării procesului de 
descompunere, cum ar fi: 

e când întregul proces s-a redus la o singură decizie sau formulă de calcul, sau o singură 

operațiune specifică bazelor de date (restaurare, actualizare, creare, ştergere sau citire); 

e când un loc de stocare reprezintă doar o singură entitate, cum ar fi: persoană, marfă, client, 
furnizor ş.a.; 

e când utilizatorii sistemului apreciază că nu au nevoie de detalii mai multe sau când analiştii 
consideră că, prin documentație, au oferit suficiente amănunte, astfel încât activităţile 
următoare din sistem să se deruleze fără probleme; 

e când un flux de date nu mai trebuie să fie descompus pentru a arăta că unor date li se aplică 
un tratament, iar altora, unul diferit; 

e când se consideră că analistul a scos în relief fiecare formular, tranzacție, ecran de 
calculator, raport printr-un flux de date, ceea ce ar putea să însemne că un nume de ecran 
sau de raport ş.a.m.d. este atribuit şi ca nume al unui flux; 

e când analistul apreciază că s-a atins cel mai de jos nivel al procesului de descompunere a 
opțiunilor meniurilor sistemului şi pentru fiecare dintre ele există câte un proces distinct. 
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Din prezentările făcute rezultă ca procesul de descompunere este destul de subiectiv. El poate 
înceta în orice moment, cu intenția de oprire definitivă, dar poate fi şi reluat ulterior, dacă se 
consideră utilă descompunerea. 

În sinteză, un sistem trebuie să fie reprezentat printr-un set de diagrame de genul celui 
prezentat în fig. 5.7, şi anume: 

1. o diagramă de context; 

2. o diagramă de nivel 0, indicând principalele subsisteme ale sistemului; 

3. până la 7 diagrame de nivel 1, indicând principalele funcții (aplicaţii) ale fiecărui 

subsistem; 

4. până la 49 de diagrame de nivel 2, indicând detaliile fiecărei funcţii sau ale fiecărei 

aplicaţii ş.a.m.d. 
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Fig. 5.7 Tehnica descompunerii diagramelor în concepția Yourdon & DeMarco 


5.2.3 Reguli de construire a diagramelor fluxurilor de date 


Diagrama fluxurilor de date poate fi utilizată în două moduri: pentru documentarea unui sistem 
existent sau pentru schițarea unuia în curs de proiectare. 

Sub formă narativă, diagramele fluxurilor de date sunt reprezentate prin text, din care, în urma 
analizei şi selectării unei metode (de exemplu, Gane&Sarson sau Yourdon&DeMarco), pot fi 
sesizate simbolurile de utilizat. 

După redactarea textului, primul pas va consta în crearea diagarmei de context (în varianta 
Yourdon&DeMarco) sau a unui tabel de entități şi activități (în varianta Gane&Sarson), prezentat 
în figura 5.8, ca „Lista intrărilor/ieşirilor din/spre entitățile externe”. 
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Entităţi externe (EE) Intrări de la EE Ieşiri spre EE 


Entitate externă 1 Date-de-intrare-1 Date-de-ieşire-2 
Entitate externă 2 — Date-de-ieşire-l 
Entitate externă 3 Date-de-intrare-2 — 


Fig. 5.8 Lista intrărilor şi ieşirilor în varianta Gane&Sarson 


Există un set de reguli aplicabile procesului de construire a diagramelor, indiferent că ele sunt 


efectuate manual sau cu instrumente CASE. O variantă prelucrată de literatura de specialitate 
prezintă regulile de respectat în procesul de creare a DFD, conform tabelului următor: 


10. 


11. 


12. 


13. 


14. 


15. 
16. 


Tabel nr. 5.1 — Reguli de construire a DFD’? 


Procese 


Nici un proces nu va putea avea doar ieşiri. Aceasta ar însemna obținerea datelor din nimic. Dacă 
un obiect are numai ieşiri, el este o sursă. 


Nici un proces nu poate avea doar intrări. Dacă un obiect are numai intrări, el poate fi o destinaţie. 
Un proces este etichetat printr-o expresie care începe cu un verb urmat de prezentarea obiectului la 
care se referă verbul. Exemplu: creare (verb) raport vânzări (obiect). 

Stocare 


Datele nu pot fi transferate direct dintr-un loc de stocare în altul. Datele pot fi transferate doar prin 
intermediul unui proces. 


Datele nu pot fi transferate direct dintr-o sursă externă într-un loc de stocare a datelor. Datele pot fi 
transferate printr-un proces care primeşte datele de la o sursă şi le transmite unui loc de stocare. 


Datele nu pot fi transferate spre o destinație externă dintr-un loc de stocare. Datele pot fi mutate 
prin intermediul unui proces. 


Un loc de stocare este etichetat printr-un substantiv. 


Entitate externă (sursă/destinaţie) 
Datele nu pot fi transferate direct de la o sursă la o destinaţie. Trebuie folosit un proces de trecere. 
O sursă/destinaţie este etichetată printr-un substantiv. 


Fluxuri de date 


Un flux al datelor are doar o singură direcție de flux între simboluri. Chiar dacă el poate fi şi 
bidirecțional, între un proces şi un loc de stocare date, pentru a sugera o citire înainte de 
actualizare, este indicată folosirea a două săgeți de sensuri contrare, şi nu una singură cu vârfuri la 
ambele capete, deoarece procesul se realizează în momente diferite. 


Ramificaţia într-un flux de date înseamnă că aceleaşi date se transferă dintr-un loc comun în două 
sau mai multe procese, locuri de stocare sau surse/destinaţii (de regulă, înseamnă copii diferite ale 
aceloraşi date). 

Asocierea (unirea) dintr-un flux de date înseamnă că exact aceleaşi date vin dintr-unul sau mai 
multe procese sau locuri de stocare, sau sursă/destinaţie spre un loc de stocare comun. 

Un flux de date nu poate reveni direct la procesul pe care l-a părăsit. Trebuie să existe cel puțin un 
alt proces prin care să treacă fluxul datelor, să se efectueze trecerea prin alte procese şi de aici să 
revină fluxul iniţial de date la procesul iniţial. 

Un flux de date spre un loc de stocare înseamnă actualizare (ştergere sau schimbare). 

Un flux de date dinspre un loc de stocare înseamnă restaurare sau folosire date. 


Un flux de date este etichetat printr-un substantiv. Pe o săgeată de flux pot apărea mai multe 
substantive însemnând un transfer gen pachet. 


? Oprea, D — Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom, laşi, 1999, pp. 221-223 
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Cele mai multe produse CASE oferă utilizatorului un sistem interactiv de lucru, prin mesaje de 
atenţionare în cazul când se încearcă includerea unei construcţii eronate într-o diagramă a fluxului 
de date sau sistemul refuză să accepte introducerea obiectului, fie în mod on-line, fie atunci când se 
solicită raportul de analiză pentru tentativa de includere a diagramei în Repository (depozitul de 
date despre... datele, obiectele şi procesele diagramei). 


5.3 Depozitul (dicţionarul) datelor 


În afara prezenţei elementelor necesare într-o DFD, se va urmări ca acestea să fie descrise 
detaliat în dicţionarul proiectului, numit depozit de informaţii (repository). În cele mai multe 
produse CASE, acest depozit este legat de diagramă, ceea ce înseamnă că pentru orice simbol al 
diagramei se va crea automat o poziţie în depozit, poziţie ce urmează să fie completată de analist. 
În general, descrierile care se realizează în depozitul datelor cu privire la componentele 
diagramelor sunt: 
e numele componentei: sunt incluse toate numele prin care se identifică fiecare element din 
diagrame, inclusiv alias-urile (pseudonime) sub care mai pot fi întâlnite aceste 
componente, cu excepţia proceselor, ale căror denumiri sunt unice; 
e tipul componentei: proces, flux de date, loc de stocare, entitate externă, dată elementară; 
e structura este diferită în funcție de tipul componentei, şi anume: 
> în cazul fluxurilor de date şi a locurilor de stocare, descrierea se realizează prin 
prezentarea datelor elementare (câmpuri, atribute) din care sunt alcătuite; 

> dacă tipul este o dată elementară, atunci descrierea se realizează prin prezentarea 
dimensiunii şi tipului de caractere folosit pentru redarea datei elementare, precum şi 
intervalul de valori în care trebuie să se încadreze (de exemplu, AA9999).; 

> un proces se descrie prin engleză structurată sau pseudocod pentru redarea 
operaţiunilor care se execută prin intermediul acelui proces; 

> pentru entitățile externe se apelează la descrierea rolului pe care îl au față de sistem, ce 
reprezintă pentru sistem, când interacționează cu sistemul etc. 

e caracteristici: este prezentată lista proceselor care interacționează cu un flux de date. În 
cazul datelor elementare, este prezentat fluxul sau locul de stocare din care provine. De 
asemenea, pot fi oferite o serie de detalii privind frecvenţa apariţiei unui flux de date, 
execuţiei unui proces, apelării unui loc de stocare, aspecte privind volumul datelor şi 
securitatea, în ideea că vor ajuta proiectanţii în stabilirea caracteristicilor fizice ale noului 
sistem. 

De exemplu, o intrare (poziție) din depozit pentru un flux de date va conţine: 

e numele fluxului, după primele linii care fac posibilă identificarea proiectului, a datei şi a 

timpului când a fost elaborat; 

e două linii de descriere a semnificației fluxului de date; 

e lista cu structura datelor elementare conținute de fluxul respectiv; 

e note suplimentare, prezentate pe un spațiu mai mare decât cel alocat inițial pentru 
descrierea semnificației fluxului; 

e o listă a locurilor (DFD) în care apare fluxul respectiv; 

e olistăa ALIAS-urilor (altor nume) atribuite aceluiaşi flux. 

Depozitul datelor oferă o descriere precisă, fără ambiguităţi a componentelor sistemului. Este 
deosebit de important ca descrierile să fie păstrate într-un singur depozit şi nu în locuri diferite, 
pentru că atunci când intervin modificări asupra unor componentele ale sistemului ele să 
influențeze toate celelalte componente cu care interacționează, fără a fi necesar să se opereze 
modificările în mai multe locuri, asigurând consistenţa descrierilor. 

Depozitul datelor, împreună cu diagramele fluxurilor de date formează modelul logic al 
sistemului. 
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5.5 Folosirea diagramelor fluxurilor de date 
în procesul de analiză 


Tot ce s-a prezentat până acum reprezintă aspecte tehnice ale construirii DFD. Dar, dincolo de 
o astfel de abordare, există şi alte aspecte importante de care trebuie să se țină seama în timpul 
analizei; ele sunt prezentate sub forma unor concepte existente în literatura de specialitate. 

Completitudinea. Conceptul de „completitudine” a DFD se referă la urmărirea includerii în 
DFD a tuturor componentelor sistemului analizat. 

Trebuie urmărit cu atenție dacă DFD conţine: 

e fluxuri ale datelor care nu au finalitate (nu duc nicăieri); 

e locuri de stocare date, procese sau entități externe care au rămas nelegate de altceva. 

Aceste stări ale lucrurilor fac ca diagramele să fie eronate sau incomplete. Când se folosesc 
instrumente CASE, ele sunt sesizabile. 

Consistența. Conceptul de „consistenţă” face trimitere la verificarea compatibilităţii între 
descrierea sistemului de pe un anumit nivel şi descrierea superioară sau descrierile inferioare. De 
exemplu, o încălcare flagrantă a consistenței se produce atunci când o diagramă apare la nivel 1, 
dar ea nu are rădăcină la nivel 0. Exemplele pot continua cu situaţia în care un flux de date este 
ataşat unui obiect al diagramei de nivel inferior, dar la nivel superior este ataşat altui obiect. 
Instrumentele CASE scot în evidenţă astfel de cazuri. 

Factorul timp. Prin diagramele fluxurilor de date nu este scos în evidență factorul timp. Nu 
rezultă că un flux de date apare constant, cu repetiție zilnică, săptămânală ş.a.m.d. De asemenea, nu 
reiese că un proces este executat într-un moment sau altul. Totuşi, timpul poate fi evidențiat prin 
diagramele stărilor de tranziție. 

Dezvoltarea iterativă. Se spune că niciodată un lucru dorit nu iese din prima încercare aşa cum 
îl vrem. De aceea, el va fi realizat încă o dată şi încă o dată, până când totul iese conform 
planificării. Se evidențiază faptul că determinarea cerințelor sistemului, structurarea lui nu sunt 
operaţiuni secvențiale ale analizei din ciclul de viață al dezvoltării sistemelor, ci sunt procese 
iterative. Se apreciază că fiecare DFD este corectată, în medie, de trei ori. Doar CASE simplifică 
acest proces iterativ, deoarece realizarea lor manuală este foarte anevoioasă. 

Primitivele diagramelor fluxurilor de date. O întrebare normală pusă de toţi analiştii este până 
când, până la cel nivel are loc descompunerea diagramelor? Se spune că procesul trebuie să 
înceteze atunci când s-a atins nivelul cel mai de jos, ceea ce, să recunoaştem, nu este prea uşor de 
controlat, aşa cum s-a văzut anterior. 

În concluzie, se poate afirma că diagramele fluxurilor de date reprezintă instrumente lejere 
pentru modelarea proceselor. 

DFD se folosesc şi în procesele de analiză a decalajelor, prin care analistul poate descoperi 
diferențele dintre două sau mai multe seturi de diagrame ale fluxurilor de date, reprezentând două 
sau mai multe stări ale sistemului informaţional sau discrepanțele dintr-o singură DFD. 

Prin analiza diagramelor finale ale fluxurilor de date se pot reliefa următoarele aspecte: 

e fluxuri de date redundante, apărute, de regulă, prin apelarea la nume diferite pentru acelaşi 

tip de date; 

e date care intră în prelucrări, dar nu sunt folosite; 

e datele ce sunt actualizate identic în mai multe locuri. 
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